The availability of Fiber Distributed Data Interface (FDDI) networks is of great interest in the telecommunication field. Telecommunication users are sensitive to response time and the guaranteed bandwidth involved in their communications through the network especially when the communications are exchanged between multimedia applications; i.e., the possibility for an Client/Server application to transmit and receive multimedia data through a telecommunication network at any instant and without delay (that is, synchronous data traffic).
Such requirements imply that the telecommunication network must be able to manage the available bandwidth and response time which are subject to change in the telecommunication network and which may degrade the telecommunication.
A Fiber Distributed Data Interface system can have dual counter-rotating fiber-optic rings operating at 100 Mega-bits per second. Fiber Distributed Data Interface uses a token-passing protocol, with each station having the chance to transmit frames when a token passes. Fiber Distributed Data Interface uses two rings, one called the PRIMARY ring arid the other the SECONDARY ring. The primary ring may be likened to the main-ring path, with the secondary ring acting as the backup ring path. Stations, if attaching directly, can attach to either or both of these rings. In order to differentiate between stations that attach to one or both rings, two classes of stations are defined. A CLASS A station attaches to both of the rings directly, while CLASS B stations attach to one of the rings.
One of the prime requirements for FDDI is a high-speed establishment backbone to interconnect heterogeneous Local Area Networks. To this end, the FDDI and LAN design must have reliability and capacity built in. Attachment cost does not have to be so carefully limited, since most of the cheaper stations, would be connected to the lower speed LANs that are themselves bridged to the FDDI backbone. FDDI has satisfied these requirements by:
Operating at a data rate of 100 Mega-bits per second, providing high capacity. PA1 Having a dual optical fiber ring configuration, that can be reconfigured by the class A stations in the event of a failure. This provides reliability and recovery. PA1 Allowing stations to attach to both of the rings or only one. PA1 SYNCHRONOUS for which a guaranteed bandwidth is required; that is a station must gain access to the ring, and transmit its frames within a specified time period. PA1 ASYNCHRONOUS traffic will only be transmitted when the load on the ring drops below a specified level. Such traffic might be file transfer where overall access or response time is not quite such an issue. PA1 The station may start to transmit synchronous frames. PA1 If the token rotation timer has not expired, that is the token was early, the remaining time is stored in the token holding timer(THT). The THT is therefore the amount of time by which the token was early. PA1 The token rotation timer is reset to the value of target token rotation time and allowed to start running down again. PA1 It determines a logical upstream neighbor address and its logical downstream neighbor address. PA1 It detects a duplicated address on an operational FDDI ring. PA1 It generates a periodic frame handshake that verifies the operation of the local station. PA1 Manage the allocation of the limited Synchronous Bandwidth rsource. PA1 Monitor the amount of Synchronous Bandwidth allocated for use. PA1 Monitor the ring for over-allocation of Synchronous Bandwidth. PA1 The SMT managed object class models the management information for an FDDI station. PA1 The MAC managed object class models the management information for the MAC entities within a station. PA1 The PATH managed object class models the management information required for the management of configuration paths within a station. PA1 The PORT object class models the management information required for the Physical Protocol/Physical Medium Dependent entities within a station. PA1 Active individual MAC allocation(s), i.e. payload PA1 TimeStamp of latest allocation modification (+/-), used in report actions PA1 SBA Category requirement, used in recovery actions PA1 Max.sub.-- T.sub.-- Neg, used in allocate and recovery actions PA1 Min.sub.-- Segment.sub.-- Size, used in allocate and recovery actions PA1 Variety of flags, signals, counters, and timers. PA1 T.sub.-- Neg change causing over-utilization PA1 T.sub.-- Neg change causing Segment.sub.-- Size violations PA1 Reconfigurations causing over-utilization PA1 Payload consistency check via SBA Reporting PA1 MIB consistency check via NIF request (Station.sub.-- State) PA1 SBA Available Policy defaulting PA1 Control fddiMACT-Neg via local access of fddiMACT-Req PA1 NONE--The SB.sub.-- Input variable is set to None when no frame is received. PA1 REQ.sub.-- ALLOCATION--The SB.sub.-- Input variable is set to Req-Allocation when a RAF Request Allocation request is received. PA1 REPORT.sub.-- RESP--The SB.sub.-- Input variable is set to Report.sub.-- Resp when a RAF Report Allocation response is received. PA1 CHANGE.sub.-- RESP--The SB.sub.-- Input variable is set to Change.sub.-- Resp when a RAF Change Allocation response is received. PA1 NIF--The SB.sub.-- Input variable is set to NIF when a NIF Request or Announcement is received with bit 6 of the station.sub.-- state set. PA1 T.sub.-- NEG--The SB.sub.-- Input variable is set to TNEG when a change in T.sub.-- Neg has been detected. PA1 UNKNOWN.sub.-- SYNC.sub.-- SOURCE--The SB.sub.-- Input variable is set Unknown.sub.-- Sync.sub.-- Source when the NIF protocol identifies an end-station currently allocated synchronous bandwidth that has not been allocated by this SBA application. PA1 N.sub.-- Change default=3 PA1 T.sub.-- Report default=3
The American National Standards Institute, in defining and developing the FDDI standard, was able to make much use of the work already done by the Institute of Electrical and Electronic Engineers. To this extent, they used a similar model for the layering of the protocols. The structure is shown in FIG. 3. The FDDI standard assumes the use of the IEEE 802.2 logical link standard; it does not attempt to define it as part of FDDI.
Medium Access Control (MAC):
In this layer, Fiber Distributed Data Interface borrows very extensively from the techniques used by IEEE, particularly the 2.5 token-ring specification. The FDDI MAC is a part of International Standard Organization 9314: ISO 9341-2. When a station wishes to transmit a frame, it must wait for a token to arrive. The token is removed from the ring by the transmitting station before actual frame transmission begins.
The frame size on a Fiber Distributed Data Interface Local Area Network is limited by clocking constraints to 4500 bytes. At the Fiber Distributed Data Interface data rate, and given the fact that a Fiber Distributed Data Interface can be physically very large, it is extremely likely that the frame will be physically shorter than the length of the ring. The frame and token structure on an Fiber Distributed Data Interface Local Area Network is shown in FIG. 4.
Allocating FDDI Capacity:
Because the token is always released before the frame header has returned, the priority reservation scheme that is used in the token-ring architecture to give stations priority access to the ring cannot work in FDDI. Additionally, FDDI is designed to give far greater control over the use of the ring capacity to connecting stations. The mechanism that is used is heavily dependent on timers within each station. FDDI defines two classes of traffic:
To control the amount of each kind of traffic that can be transmitted by a station, FDDI implements a timer token access protocol. Stations expect to see a token within a specified time interval. This interval is known as the target token rotation time (TTRT). All stations have the same value for the target token rotation time set within them. The value is determined when a station initializes itself on the ring.
Each station measures the time between successive appearances of a token. The station uses a token rotation timer (TRT) to do this. When a token passes a station, the token rotation timer is set to the value of the target token rotation time and starts to count down. If the target rotation timer expires before the next token is seen, a counter called the late counter is incremented. The token is said to be late. Under normal circumstances, the token should reappear within the target time. The token is then said to be early. Each time a station sees a token, three things happen:
The station is allowed to transmit synchronous frames until a time allocated for synchronous data transmission expires (the synchronous allocation timer). This timer value may be different at each station, but the sum value of all the synchronous allocation timers on active stations must always be slightly less than the TTRT. It is up to the station management protocols to make sure that this is so.
When the timer expires, or all synchronous frames are transmitted, the station may be allowed to transmit asynchronous frames. The decision is based on the value of the late count. If the count is at zero, asynchronous frames can be transmitted for the length of time that was stored in the TTRT. When this timer runs down to zero, transmission must stop, and a token must be released.
Meanwhile, the TRT is steadily running down. It has been doing so during both synchronous and asynchronous transmission. If both of these transmissions were stopped because of timer expiration (token holding and synchronous allocation) and assuming that other stations have frames to send, the TRT will almost certainly expire before the token is seen again. The token is late; the late counter will be incremented, there will be no value to put in the TTRT, and the station will not be allowed to send any asynchronous frames the next time it does see the token. In a way, the station has paid a penalty for having had so much traffic to send. This penalty only applies to asynchronous traffic however; a station may always transmit synchronous traffic when it sees a token.
When the token next arrives early, the late counter is decremented. When the value gets to zero, the station will be able to transmit asynchronous traffic once more.
When this operation is considered across all stations on the ring, the capacity allocation algorithm is attempting to keep the actual token rotation time less than the target. Since synchronous traffic can always be sent, the mechanism guarantees an amount of bandwidth to the synchronous traffic. Asynchronous traffic is only sent when there is spare capacity on the LAN, and fairness of station access is maintained.
Using this mechanism, a FDDI network is able to cope with traffic needing a defined amount of Synchronous Bandwidth (i.e. multimedia traffic), and also support the burst traffic whose response time requirement is less defined.
Physical Protocol (PHY):
As in the IEEE standards, the physical layer specifies the signalling rate, encoding and clocking of the LAN. For FDDI the data rate on the ring is 100 Mega-bits per second. The Fiber Distributed Data Interface Physical Protocol is a part of International Standards Organization 9314: ISO9341-1
Physical Medium Dependent (PMD):
This layer is used to specify the fiber type and size used by FDDI, the connectors, and the wavelength of the light beam that is transmitted down the fiber. The Fiber Distributed Data Interface Physical Medium Dependent is a part of International Standard Organization 9314: ISO9341-3
Station Management (SMT): This layer defines the protocols that stations use to intercommunicate, so as to set their timers; the target token rotation timer or their synchronous allocation timers for example. Without a consistent set of protocols which are used by all stations that attach to the ring(s), it is impossible for FDDI to deliver the function, capacity and performance for which it was designed. The FDDI Station Management is a part of American National Standards Institute X3T9: ANSI X3T9-5.
Station Management provides a number of Frame-Based services and functions that may be used by higher-level functions to gather information about and exercise control over the attached FDDI network. A number of the Station Management frame protocols are request-response frame protocols. These protocols are carried out between a single requester and one or more responders, depending on the addressing mode of the request frame.
NEIGHBOR NOTIFICATION This protocol performs the following functions:
The protocol performs these functions by periodically initiating a request-response frame exchange between a station and its nearest downstream neighbor. The frames used are the Station Management Neighbor Information Frames.
Status Report Protocol A station performs the Status Report Protocol to periodically announce Station Status that is useful in managing an FDDI network. This status information is carried in Status Report frames.
Parameter Management Protocol This protocol performs the remote management of station attributes. It is accomplished via Parameter Management frames. The Parameter Management prtocol operates on all Station Management Management Information Base MIB) attributes, attribute groups and actions.
STATION STATUS POLLING A mechanism is provided for aggregate Station Status to be obtained remotely through a polling (request/response) protocol. This protocol is carried out using the Status Information frame.
ECHO PROTOCOL This protocol is provided for station-to-station loopback testing on a FDDI ring. The Echo protocol is carried out using Echo frames, which may contain any amount up to maximum frame size supported by the FDDI standards, of implementation/specific Echo data.
EXTENDED SERVICE PROTOCOL This protocol is provided for extending new SMT frame-based services. All ES frames use a unique ESF.sub.-- ID SMT parameter which identifies the extended service being supplied. The protocol and semantics of these frames are specific to the particular ESF.sub.-- ID carried by the frames.
SYNCHRONOUS BANDWIDTH ALLOCATION This protocol provides for a deterministic mechanism for allocation of Synchronous Bandwidth and supports monitoring for over-allocation of synchronous and total bandwidth. The protocol supports the following functions:
The protocol performs the allocation functions through a request-response frame exchange between a station using Synchronous Bandwidth and a Synchronous Bandwidth management process. The frames used are the Resource Allocation frames.
The Station Management provides the specification of management information related to the operation of the Station Management. This information that is supplied to higher-level function (i.e., System Management) is represented using an object oriented approach consistent with the approach taken by Organization Standard International Management Standards. Station Management Information is described in terms of Managed Objects. The Station Management standard defines four Managed Object Classes.
FIG. 5 shows an example of a FDDI network allowing communication between server station and client stations via a FDDI ring. Server station which can be for example an IBM RISC/6000 System computer is connected to the ring. Similarly client stations which can be for example IBM Personal System/2 computers connected to the ring. Server station is loaded with its respective application programs such as video server or graphic data server. Server station and client stations being connected to the same FDDI network, are loaded with Station Management program.
Today's FDDI networks do not use FDDI synchronous transmission; however, the interest in FDDI synchronous transmission is gaining momentum as a viable transmission alternative for the emerging multimedia applications. This momentum is fueled by the FDDI Synchronous Implementer's Agreement (IA), developed by the FDDI Synchronous Forum, which provides the basis for Allocation of Synchronous Bandwidth over Fiber Distributed Data Interface. The allocation of Synchronous Bandwidth over a FDDI network is performed by using the Resource Allocation frame protocol. This protocol assumes one central allocator of the Synchronous Bandwidth resource, and provides for the management of SBA, the detection of over allocation, and ability to recover from faults due to over-allocation. FIG. 6 shows an example of an allocation of Synchronous Bandwidth.
A station must receive an allocation of SB before initiating synchronous transmission.
A station that wants to change its current allocation of SB must request the new allocation amount from the SBA Management station.
To request a change in allocation, a station sends a Resource Allocation frame Request (Request Allocation) to a SBA Management station. A SBA Management station will respond with a Resource Allocation frame Response indicating success or failure of the request. If the request fails, the station may adjust its allocation request to within the available bandwidth specified in the response frame and restart the exchange. The Station changes its SB attributes (i.e., in the Management Information Base) when response indicates successful allocation.
The following describes the content of the current FDDI Synchronous Implementer's Agreement. The SBA section of the SMT standard does not define the algorithm(s) used to allocate synchronous bandwidth. An example implementation is defined here including all mandatory SBA functionality. The synchronous allocation request processing is straight/forward, whereas the process of deallocation due to over-utilization or inconsistencies is not. The SBA complexities are in various SBA Actions where deallocations are generated and in the allocation data structures where many SBA parameters are maintained.
The required IA SBA functions are listed below with an example SBA state diagram detailing the IA implementation.
Maintain an SBA Allocation MIB
These data structure(s) maintain all the necessary SBA information used by the SBA state diagram. The SBA state diagram example identifies important elements of these data structures. The SBM internal state diagram uses a (N) notation to identify which end-station substructure is or shall be modified. An example of the information maintained in an SBA data structure for a synchronous end-station is.
Recover From
Other Required SBA Functionality Includes